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Foreword 



This Technical Specification (TS) has been produced by ETSI Project Pay Terminals and Systems (PTS). 

TS 101 206-7 version 1.1.1 is the handover version to Comite Europeen de Normalisation (CEN) for becoming 

EN 726-7. 

TS 101 206-3, 4 and 7 version 1.2.1 represent an update of the documents handed over to CEN for becoming 

EN 726-3, 4, and 7. PTS has used version 1.2.1 rather than the handover version to CEN (version 1.1.1) for producing 

the conformance testing specification for EN 726-3, 4 and 7. 

ETSI has produced a set of TSs which are not a copy of any CEN published EN. The TSs are complete and consistent 
documents with references among themselves. It has been made clear in these TSs that they are contributions to the 
CEN work for publication as EN (after re-editing the references). Once published by CEN as EN, ETSI will withdraw 
its TSs. 

History of EN 726 

EN 726 was prepared by ETSI Technical Sub-Committee (STC) Terminal Equipment 9 (TE9), adopted by CEN/TC 224 
and submitted to the CEN formal vote. 

EN 726 consists of seven parts covering Identification card systems; Telecommunications Integrated Circuit (IC) cards 
and terminals; as identified below: 

Parti: "System overview"; 

Part 2: "Security framework"; 

Part 3: "Application independent card requirements"; 

Part 4 "Application independent card related terminal requirements"; 

Part 5: "Payment methods"; 

Part 6: "Telecommunication features"; 

Part 7: "Security module". 

Overview of ETSI deliverables on EN 726 family 



TS 101 206-1 


"Identification card systems; Telecommunications IC cards and terminals; Part 1: System overview". 


TS 101 206-3 


"Identification card systems; Telecommunications IC cards and terminals; 
Part 3: Application independent card requirements". 


TS 101 206-4 


"Identification card systems; Telecommunications IC cards and terminals; 
Part 4: Application independent card related terminal requirements". 


TS 101 206-7 


"Identification card systems; Telecommunications IC cards and terminals; Part 7: Security module". 


Overview of ETSI deliverables on EN 726 conformance testing family 


TS 101 203-1/2/3 


"Identification card systems; Telecommunications IC cards and terminals; 
Test methods and conformance testing for EN 726-3". 
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TS 101 204-1/2/3 



"Identification card systems; Telecommunications IC cards and terminals; 
Test methods and conformance testing for EN 726-4". 



TS 101 207-1/2/3 



"Identification card systems; Telecommunications IC cards and terminals; 
Test methods and conformance testing for EN 726-7". 
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1 Scope 

The present document specifies: 

a) the minimum security requirements for a Security Module (SM); 

b) the general card related functions embedded in the SM - terminal protocols including minimum data exchange. 
The data elements and cryptographic processing described in annex A for the case where the SM is an IC card 
shall be supported if the SM is not an IC card or the configuration of the system, e.g. where the SM handles more 
than one terminal/user card. Configurations where the SM handles more than one terminal/user card are not fully 
described in the present document. Further mechanisms may be required to enable these configurations; 

c) the necessary security services and mechanisms to provide application and cryptographic security information for 
the processing of telecommunication transactions; 

considering several types of SM at different locations in the system and different system configurations. 

The present document allows interaction between the IC card and the SM via the terminal in a way that may be 
functionally transparent to the terminal and possibly also the network(s). This provides the flexibility to use different 
techniques, commands and message formats at the terminal - SM interface. 

The present document supports IC cards with payment applications following EN 726-5 [3] and all card applications 
following clauses 4 to 7 of the present document. The present document supports IC cards following TS 101 206-3 [2]. 
Other telecommunication IC cards which do not follow EN 726, e.g. simple memory cards, may also be supported by 
the SM described in the present document. 



References 



References may be made to: 

a) specific versions of publications (identified by date of publication, edition number, version number, etc.), in 
which case, subsequent revisions to the referenced document do not apply; or 

b) all versions up to and including the identified version (identified by "up to and including" before the version 
identity); or 

c) all versions subsequent to and including the identified version (identified by "onwards" following the version 
identity); or 

d) publications without mention of a specific version, in which case the latest version applies. 

A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

[1] EN 726-2: "Identification Card Systems - Telecommunications Integrated Circuit Cards and 

Terminals - Part 2: Security framework". 

[2] TS 101 206-3: "Identification card systems; Telecommunications IC cards and terminals; 

Part 3: Application independent card requirements". To become EN 726-3. 

[3] EN 726-5: "Identification Card Systems - Telecommunications Integrated Circuit Cards and 

Terminals - Part 5: Payment methods". 

[4] ISO/IEC 7816: "Identification cards - Integrated circuit(s) with cards contacts - 

Part 1: Physical characteristics (1987)". 

Part 2: Dimensions and locations of the contacts (1988)". 

Part 3: Electronic signals and transmission protocols (1990)". 

Part 4: Inter industry commands for interchange (1995)". 
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Part 5: Numbering system and registration procedure for application identifiers". 

Part 6: Interindustry data elements". 

[5] ISO/IEC 10202: "Financial Transactions cards - Security architecture of financial transaction 

systems using integrated circuit cards 

Part 4: Secure application module". 

Part 5: Use of algorithms". 

[6] ISO 4217: "Codes for the representation of currencies and funds". 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following definitions apply: 

Access Conditions (AC): A set of security attributes associated to a file. 

application: An application consists of a set of security mechanisms, files, data and protocols (excluding transmission 
protocols) which are located and used in the IC card and outside the IC card (external application). 

Application Provider (AP): The entity which is responsible for the application after its allocation. One AP may have 
several applications in one card. The files allocated in the card corresponding to one application are called a card- 
application. There may exist several applications on a given card from the same application provider or from several 
application providers. 

application session: A link between the card application part and the external world application part of the same 
application. 

Application Specific Command set (ASC): To a DF can be associated, optionally, an ASC-set (an application specific 
command set and/or an application specific program). This means that when selecting this application, the general 
command set is extended or modified by this specific command set. The ASC is valid for the whole subtree of this 
application unless there are other ASCs defined at the lower levels of this application. 

card: A multi-application card can be considered as a set of files, some of them shared by the different application 
providers and/or the card issuer, other files owned exclusively by the different application providers or the card issuer. 
Files can, e.g., be read, written or executed. 

Dedicated File (DF): A file containing AC and allocatable memory. It may be the parent of elementary files and/or 
dedicated files. 

Elementary File (EF): A file containing AC, data or a program and no other files. 

EFpjjj is an elementary file at the MF or at DF level, which contains a list of all, or part of, available applications in 
the card (see also ISO 7816-5 [4]). 

EFj£) is an elementary file at the MF level, containing the identification number of the card. 

^^ICC ^^ ^'^ elementary file at the master file level, containing general information concerning the IC and IC card. 

EF|^£Y OP i^ '^^ elementary file containing operational keys. 

EF|^£Y MAN i^ ^'^ elementary file containing management keys. 

EFpji^ OP i^ '^^ elementary file containing diversified operational keys. 

EFpji^ MAN i^ ^'^ elementary file containing diversified management keys. 

file IDentifier (ID): Each file (MF, DF, EF) has an identifier consisting of 2 bytes. 
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key qualifier: An unambiguous set of data to select a specific keyset in the SM. 

Master File (MF): The mandatory unique file representing the root of the file structure and containing AC and 
allocatable memory. It may be the parent of elementary files and/or dedicated files. 

operating system: That which is required to manage the logical resources of a system, including process scheduling and 
file management. 

path: Concatenation of file identifiers without delimitation. 

secrets: Algorithm(s), related key(s), security procedures and information. 

Security Module (SM): A device containing logically and physically protected secrets - algorithm(s), related key(s), 
security procedures and information to protect applications in such a way that unauthorized access is not feasible. In 
order to achieve this the module may in addition be further physically, electrically and logically protected. 

security module provider: See ISO/IEC 10202-4 [5]. 

sequence control: A feature assuring that operations, invoked by commands, can only be performed by the SM in 
allowed, predefined order(s). 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AC Access Condition 

AID Application IDentifier 

AUT Authenticated 

BCD Binary Coded Decimal 

CEN Comite Europeen de Normalisation 

CHV Card Holder Verification information 

DF Dedicated File 

EF Elementary File 

EN European Norm 

EW External World 

IC Integrated Circuit 

ID Identifier of a file 

IFD InterFace Device 

INT.AUTH Internal Authentication 

INV Invalidate 

LEN Length 

MAC Message Authentication Code 

MF Master File 

NEV Never 

PIN Personal Identification Number 

PRO Protected 

RAN Random 

REH Rehabilitate 

RFU Reserved for Future Use 

SM Security Module 

STC Technical Sub-Committee of ETSI 

TC Technical Committee 

TE9 Terminal Equipment 9 (Technical Sub-Committee, STC, of ETSI) 

UC User Card 



4 Physical characteristics of the SM 

If the SM is an IC card the physical characteristics shall be in accordance with TS 101 206-3 [2], clause 4. 
For any other case the physical characteristics are out of the scope of the present document. 
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5 Electronic signals and transmission protocols 

If the SM is an IC card the electronic signals and transmission protocol(s) shall be in accordance with TS 101 206-3 [2], 
clause 5. 

For any other case the electronic signals and transmission protocol are out of the scope of the present document. 



Logical model for SM 



A SM following the present document contains: 

a) permanent secrets (master key(s)); 

b) temporary secrets (diversified key(s)); 

c) a balance (optional); 

d) an operating system to handle secure access to the secrets mentioned above. Additional options are possible as 
long as they do not interfere with the basic contents, but are out of the scope of the present document. 



Physical interface 



Transmission interface 



ISO/IEC 7816-3 

ISO/IEC 7816-3 
e.g.T=0,T=l 



Application independent interface EN 726-3 

Up to implementation 



Operating system 



Algorithms 



Ba la nc e 



File set 



Master 
key(s) 



Diversified 
key(s) 



Options* 



*One of the optionscould be prevention of physical attacks 



Figure 1 : General structure of a SM 
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EN 726-5/6 
























EN 726-7 


EN 726-3/4 




EN 726-7 




EN 726-7 


EN 726-3 


** 


EN 726-7* 


ISO/IEC 7816-3 


** 


ISO/IEC 7816-3* 


ISO/IEC 7816-2/3 


** 


ISO/IEC 7816-2/3* 













*only if the SM is an ICC (otherwise out of scope) 
**out of scope 

For the purpose of this figure, the application master is the equipment which is issuing commands to the UC and SM 



Figure 2: Standardized communication between a UC and a SIVI 



General concepts 



7.1 General security principles 



The SM provider shall be responsible for the life cycle of the SM. 

Any aspect in the operation of a SM or data obtainable from a SM shall NOT compromise the security of the system. 

Cryptographic keys used in the SM and the UC shall be managed in such a way that the security of any system using 
SMs or UCs is not compromised. 

During the application life cycle the need to change keys in the UC may appear. To support this the SM may contain 
several keyset versions. 

Interoperability of telecommunication SMs in Europe is based on the exchange of secret keys. The mechanisms for 
downloading keys into the SM are not describe in the present document. The isolation of the key management systems 
between different operators requires the use of a trusted party. 



7.1.1 



Access Conditions (AC) 



For the functions described in this part of the standard no ACs have to be fulfilled in the SM, but the usage of the keys 
may be restricted. The SM uses diversified keys for functions in the UC where the ACs require a key operation. For the 
management of the SM by the external world, the ACs defined in TS 101 206-3 [2] shall apply only if the SM is an 
IC card. 

The SM may also perform a key diversification for application specific functions in the UC which are not defined in 
TS 101 206-3 [2]. In this case, the SM shall restrict the usage of the key(s) to these specific function(s). 



7.1.2 Sequence control 



A sequence control can be achieved by using ACs of the UC on the SM. Sequence control functions where the SM 
checks if it is allowed to perform commands and status responses can optionally be added if needed in the application. 
The implementation is out of the scope of the present document. Nevertheless the following applies, if the command is 
allowed the operation will be performed and the results will be the outcome of the command. If the command is not 
allowed the operation will not be performed and the status conditions will contain "Command out of sequence". 
The internal reaction of the SM is application dependent. 
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7.2 SM Life cycle 

See ISO/IEC 10202-4 [5]. 

7.3 Configuration of the system 

The general card related functions at the SM - terminal interface including minimum data exchange. 
The user card - terminal interface shall not be affected by type of implementation of the SM. 

Four possible configurations of the SM are shown in figures 3 to 6. 

In the interests of completeness all four locations are shown. However, it is probable that for the more distant locations a 
higher level transport protocol may be appropriate. Such high level transport protocols are outside the scope of the 
present document. 
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Figure 4: SIVI included in a local concentrator 
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Figure 5: SM in the network 
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Figure 6: Remote SM 



15 



TS101 206-7 V1 .2.1 (1998-01) 



A distinction between normal operations (transfer of sensitive data such as payment transactions) and more sensitive 
operations (such as creation of sensitive data) may be necessary. In this case, two kinds of SM may exist. SMI situated 
in an open environment only allowing normal operations and SM2 (and terminal) located in a secure environment and 
allowing in addition e.g. personalization. 

For SMs covering more sensitive operations, specific security tools are necessary as physical protection. 
These requirements are out of the scope of the present document. 
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Figure 7: An example of a system configuration 



7.4 SM security functions 

A SM contains: 

a) secrets which allow the terminal to access protected parts of the UC; 

b) secrets which allow the authenticity of the UC to be checked; 

c) optionally, a balance that can be increased and decreased in a secure manner in the SM, coupled with a 
corresponding reverse operation in the UC. 

A SM shall be logically and physically protected against attacks aimed at exposing or abusing secrets during the whole 
life cycle of the SM. 

All functions shall be independent of transmission protocols. 

These may be different at the terminal - UC and at the terminal - SM interface. 

In order to fulfil the AC = Authenticated (AUT) or Protected (PRO) of files in the User Card (UC), any related 
functions in the UC and the SM shall use the same keys and algorithms. 

For the purpose of the present document the functionality is based on: 

a) symmetric algorithms; 

b) diversified keys. 

However, the use of asymmetric or hybrid crypto systems may be defined later. 



16 



TS101 206-7 V1 .2.1 (1998-01) 



8 



Description of the functions of a SIVI 



This clause only describes the additional specific functions necessary for a SM. If the SM is an IC card the remaining 
part of this clause and annex A apply. Additional functions to support other applications outside the scope of EN 726 are 
not precluded. Any such function shall not conflict with the content of EN 726. The command header and trailer referred 
to in this clause are data elements used to control the processing of data by the SM in accordance with the function 
specified. 



8.1 



Functions without IVIAC 



8.1.1 SELECT KEYSET 



The purpose of this function is to unambiguously address a specific keyset in the SM, that shall be used at least for the 
next cryptographic computation, corresponding to the specific command, file, AC and application of the UC. 
In case a UC following the present document is used, the SM shall select a keyset corresponding with the key file 
version indicated by the UC. 



Input: 



a/ command header; 
b/ key qualifier. 



Table 1 : Key qualifier (in case of a MF of the UC) 



Bytes 


Description 


Length 


1 -4 


IC card manufacturing references (coded according to 
IS 101 206-3 [2]) 


4 bytes 


5 


Card personalizer ID (coded according to IS 101 206-3 [2]) 


1 byte 


6-7 


File ID of the EF^fy 


2 bytes 


8 


Keyfile version (coded according to IS 101 206-3 [2]) 


1 byte 


Table 2: Key qualifier (in case of a DF in the UC) 


Bytes 


Description 


Length 


1 -X 


Application IDentifier (AID) 

(coded according to IS 101 206-3 [2]) 


1 - 16 bytes 


(X+1)-(X+2) 


File ID of the EF^fy 


2 bytes 


X+3 


Keyfile version (coded according to IS 101 206-3 [2]) 


1 byte 



Output: 



a/ data: none; 
b/ status. 
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8.1.2 DIVERSIFY KEYSET 

The purpose of this function is to derive temporary keys from all the master keys contained in the previously selected 
keyset using application specific diversification data. The temporary keys are written in a specific temporary file. 
After key diversification, this temporary file becomes relevant for the DF in the UC. 

This diversified keyset is kept in the SM and is valid until the next diversification using the same master keyset takes 
place. 

NOTE: To increase the prevention of misuse of diversified keys sequence control can be used. 

All secret keys, diversified as well as master keys, shall never (NEV) be allowed to be read out from the SM. 

Pre-conditions: before the DIVERSIFY KEYSET function is performed, the relevant keyset shall be selected by 
use of the SELECT KEYSET function. 



Input: 



a/ command header; 
b/ diversification data; 
c/ algorithm ID. 



Table 3: Diversification data 



Bytes 


Description 


Length 


1 -X 


Diversification data (application dependent) 


1 - 16 bytes 



Output: 



a/ data: none; 
b/ status. 



8.1.3 ASK PARAMETER 

The purpose of this function is to transfer a parameter from the SM to the terminal. 

This parameter is given to the terminal and used inside the SM to compute the next incoming cryptogram. 

This parameter shall be valid until the next function requiring a challenge is performed in the SM except in the case of 
VERIFY MAC. In the case of VERIFY MAC only, the parameter shall remain valid for a subsequent function. 

Types of parameters: 

a) Challenge (random); 

b) Challenge (counter). 

Several counters for providing challenges, related in different keysets, may exist. In case of multiple counters the 
counter related to the previously selected keyset shall be used to provide the challenge, else a common SM-counter shall 
be used. 

NOTE 1 : It is proposed not to specify the counter structure for the case the SM is an IC card in order to allow 
flexibility for the way the works. 

NOTE 2: For some applications a counter, e.g. a transactions number, may be used instead of a random number. 
In case the SM not being an IC card functionality shall be equivalent to what is described in 

subclause A. 5. 3.1. 



Input: 



Output: 



a/ command header; 
b/ type of parameter 
c/ length, 
a/ parameter; 
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Table 4: Parameter 



Bytes 


Description 


Length 


1 -X 


Challenge 


X bytes 



b/ status. 

8.2 Functions used to compute a cryptogram or MAC 

If TESA 7 is used, a cryptogram is computed according to TESA 7 mode "authentication" (see EN 726-2 [1], 
subclauses A. 3.1 and A. 3.2) and MAC is computed according to TESA 7 mode Message Authentication Code ("MAC") 
(see EN 726-2 [1], subclauses A.2.3 and A.2.4). 

NOTE: In other parts of the present document the result of the MAC computation may be also referred as 
"cryptogramm". 

8.2.1 COMPUTE LOAD KEY 

The purpose of this function is to provide an enciphered key and the related cryptogram to the UC. The SM shall 
perform an encipherment of the key (indicated in the input parameters) of the previously selected keyset. The key used 
to perform the encipherment shall be indicated in the command header of COMPUTE LOAD KEY. The enciphered key, 
the contents of the data field and the challenge previously given by the UC shall be used to provide a cryptogram. 
The input data for this function contains the necessary parameters used in the UC for verifying the cryptogram. 



1 Comma 


Para meters of the LOAD KEY FILE command 

1 


Trailer | 


1 1 
nd headarlNSi PI i P2 i Lc i Data i 


COMPmELDADKEY 



Figure 8: General structure of COMPUTE LOAD KEY 



Pre-conditions: the challenge used to compute the cryptogram shall be obtained from the UC by an ASK 
RANDOM function and transmitted by the terminal to the SM using a GIVE RANDOM; 



Input: 



the keyset shall be selected using the SELECT KEYSET function. The relevant key file shall be 
the one containing the keys after diversification. 

a/ command header/trailer (COMPUTE LOAD KEY); 

b/ data (parameters of the following UC command): 
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Table 5: Data 



Bytes 


Description 


Length 


1 


INS byte of the following LOAD KEY FILE command sent to the 
UC (Coded according to TS 101 206-3 [2]) 


1 byte 


2 


P1 of the following LOAD KEY FILE command sent to the UC 
(coded according to TS 101 206-3 [2]) 


1 byte 


3 


P2 of the following LOAD KEY FILE command sent to the UC 
(coded according to TS 101 206-3 [2]) 


1 byte 


4 


L^ of the following LOAD KEY FILE command sent to the UC 
(coded according to TS 101 206-3 [2]) 


1 byte 


5 


Key file version (only present if key number 0) 


1 byte 


6 


Key length 


1 byte 


7 


Algorithm identifier 


1 byte 



Output: 



c/ key number (indicated in the command header of the LOAD KEY command (P2)); 

d/ EFj^Y type (EFj^gY MAN '^^ E^KEY Op) indicated in the command header of the LOAD KEY 
FILE command (PI). 

a/ response data; 



Table 6: Response data 



Bytes 


Description 


Length 


1 -16 


Enciphered key 


1 6 bytes 


17-24 


MAC 


8 bytes 



b/ status. 

8.2.2 COMPUTE MAC 

For functions in the UC which need a MAC in order to fulfil the ACs, the general function COMPUTE MAC shall be 
used in the SM to calculate the MAC. The input data for this function contains the necessary parameters used in the UC 
for verifying the MAC (command header and data). 



Para meter of the UC command 

: ^ , 

I Command header; INS I PI i P2 i Lc i Dat^None [Trailer | 



COMPUTE MAC 



Figure 9: General structure of COMPUTE MAC 
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Pre-conditions: the challenge used shall be obtained from the UC by an ASK RANDOM function and transmitted 
by the terminal to the SM using a GIVE RANDOM; 



Input: 



the keyset shall be selected using the SELECT KEYSET function. The relevant key file shall be 
the one containing the keys after diversification. 

a/ command header/trailer (COMPUTE MAC); 

b/ data (parameters of the following UC command): 

Table 7: Data 



Bytes 


Description 


Length 


1 


INS byte of the following command sent to the UC (Coded 
according to TS 101 206-3 [2]) 


1 byte 


2 


PI of the following command sent to the UC (coded according to 
TS101 206-3 [2]) 


1 byte 


3 


P2 of the following command sent to the UC (coded according to 
TS101 206-3 [2]) 


1 byte 


4 


L^ of the following command sent to the UC (coded according to 
TS101 206-3 [2]) 


1 byte 


5 - (4+X) 


The data field of the following command sent to the UC (Coded 
according to TS 101 206-3 [2]) 


X bytes 



c/ key number (indicated in the command header if SM is an IC card). 
Output: a/ MAC (UC command header, data): 

Table 8: Cryptogram 



Bytes 


Description 


Length 


1 -X 


MAC 


X bytes 



b/ status. 
NOTE: The length x depends on the cryptographic algorithm application. In case of TES A 7, x = 8. 

For the following functions in the UC, the COMPUTE MAC function is applicable when AC = PRO: 

CREATE FILE 
DELETE FILE 
EXTEND 
EXECUTE 
UPDATE BINARY 
UPDATE RECORD 
CREATE RECORD 
INVALIDATE 
REHABILITATE 
WRITE BINARY 
WRITE RECORD 
DECREASE 
CREATE RECORD 



The purpose of these functions is to prove that the SM has been involved in a given transaction and that the function it 
was to perform has been accomplished. 
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8.2.3 COMPUTE CRYPTOGRAM 

This function shall be used to compute the cryptogram used in the user card in the EXTERNAL AUTHENTICATION 
command. 

Pre-conditions: the challenge used shall be obtained from the UC by an ASK RANDOM function and transmitted 
by the terminal to the SM using a GIVE RANDOM; 

the keyset shall be selected using the SELECT KEYSET function. The relevant key file shall be 
the one containing the keys after diversification 

Input: a/ command header/trailer (COMPUTE CRYPTOGRAM); 

b/ key number (indicated in the command header if SM is an IC card). 

Output: a/ cryptogram; 

Table 9: Cryptogram 



Bytes 


Description 


Length 


1 -X 


MAC 


X bytes 



b/ status. 

8.2.4 COMPUTE MAC External World (EW) 

The purpose of this function is to add a cryptogram to the input data given to the SM to provide the external world with 
a proof of 

the authenticity of the SM involved in the transaction; 

the integrity of the data during transmission from SM to the external world. 

The input data for this function contains parameters of the same structure as a command header in the UC. 



Para meter of the UC command 
I ^ , 

I Command headeri INS I PI i P2 i Lc i Dat^None i Trailer | 



COMPUTE MAC EW 



Figure 10: General structure of COMPUTE MAC EW 
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Pre-conditions: the challenge used shall be obtained from the SM by an ASK PARAMETER function before. 
Input: a/ command header/trailer (COMPUTE MAC EW); 

b/ data: 

Table 10: Data 



Bytes 


Description 


Length 


1 


INS byte of the following command sent to the UC 


1 byte 


2 


P1 of the following command sent to the UC 


1 byte 


3 


P2 of the following command sent to the UC 


1 byte 


4 


L^ of the following command sent to the UC 


1 byte 


5 - {4+X) 


The data field of the following command sent to the UC 


X bytes 



c/ key number (indicated in the command header if SM is an IC card). 
Output: a/ cryptogram (command header, data): 

Table 1 1 : Cryptogram 



Bytes 


Description 


Length 


1 -X 


MAC 


X bytes 



NOTE: 



b/ status. 

The length x depends on the cryptographic algorithm application. In case of TES A 7, x : 



8.2.5 DECREASE (SM) 



The purpose of this function is to decrease a balance in a SM by the amount that will be added to the counter value of a 
valid UC (reload). The SM shall check if the indicated key is allowed to perform this function. 



1 Comma 


nd head 


Par 

er 


ametersofthe INCREASE/ INCREASE STAMPED 

1 


command 
Trailer | 


1 

ilNS 1 PI |P2 iLc 1 


1 
Data 1 


DECREASE(SM) 



Figure 11 : Structure of DECREASE (SM) 

Pre-conditions: the challenge used shall be obtained from the UC using an ASK RANDOM function and 
transmitted to the SM using a GIVE RANDOM; 

the keyset shall be selected using the SELECT KEYSET function. The relevant key file shall be 
the one containing the keys after diversification; 

the file to be decreased in the SM has to be selected. 

NOTE: It is recommended that the remaining value in the UC is obtained to check if the reload amount will 
exceed the maximum value defined before decreasing the SM. This could be done by issuing a 
DECREASE function with the amount equal to zero to the UC. 



Input: 



a/ command header/trailer (DECREASE (SM)); 

b/ Key number (included in the command header); 

c/ data (parameters of the INCREASE or INCREASE STAMPED (UC) command). 
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Table 12: Data field of the DECREASE (SM) command 



Bytes 


Description 


Length 


1 


INS byte of the following INCREASE or INCREASE STAMPED 
command sent to the UC (coded according to TS 101 206-3 [2]) 


1 byte 


2 


PI of the following INCREASE or INCREASE STAMPED 
command sent to the UC (coded according to TS 101 206-3 [2]) 


1 byte 


3 


P2 of the following INCREASE or INCREASE STAMPED 
command sent to the UC (coded according to TS 101 206-3 [2]) 


1 byte 


4 


The L^ of the following INCREASE or INCREASE STAMPED 
command (coded according to TS 101 206-3 [2]) 


1 byte 


5 - (4+X) 


The data field of the following INCREASE or INCREASE 
STAMPED command sent to the UC (coded according to 
TS101 206-3 [2]) 


X bytes 



Output: 



a/ MAC: 



Table 13: DECREASE (SM) response 



Bytes 


Description 


Length 


1 -X 


MAC 


X bytes 



NOTE: The length x depends on the cryptographic algorithm application. In case of TES A 7, x = 8. 
b/ status. 
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8.3 Functions verifying cryptograms or IVIAC 

If TESA 7 is used, a cryptogram is computed according to TESA 7 mode "authentication" (see EN 726-2 [1], 
subclauses A3.1 and A3 .2) and MAC is computed according to TESA 7 mode "MAC" (see EN 726-2 [1], 
subclauses A2.3 and A2.4). In other parts of the present document the result of the MAC computation may be also 
referred as "cryptogramm". 



8.3.1 



VERIFY IVIAC 



The purpose of this function is to verify a MAC performed in the UC. The SM shall check if the indicated key is 
allowed to perform this function. 



1 Command header 






Para meters of the UC command 

1 




1 
ilNS 


PI 


1 P2 1 Le 1 Data'none , 


1 
MAC 1 


VERIFY MAC 



Figure 12: Structure of VERIFY MAC 



Pre-conditions: the challenge used shall be obtained from the SM using an ASK PARAMETER function and 
transmitted to the UC using a GIVE RANDOM; 

the keyset shall be selected using the SELECT KEYSET function. The relevant key file shall be 
the one containing the keys after diversification. 

Post-conditions: the challenge used by the command shall be kept and usable for the next command with pre- 
condition ASK PARAMETER; 



Input: 



a/ command header/trailer (VERIFY MAC); 

b/ Key number (indicated in the command header); 

c/ data (parameters of the previous UC command/response). 
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Table 14: Data 



Bytes 


Description 


Length 


1 


INS byte of the previous command sent to the UC (Coded 
according to TS 101 206-3 [2]) 


1 byte 


2 


PI of the previous command sent to the UC (coded according to 
TS101 206-3 [2]) 


1 byte 


3 


P2 of the previous command sent to the UC (coded according to 
TS101 206-3 [2]) 


1 byte 


4 


The Lg of the previous command sent to the UC (Coded 
according to TS 101 206-3 [2]) 


1 byte 


5 - {4+X) 


The data field of the previous response sent by the UC (Coded 
according to TS 101 206-3 [2]) 


X bytes 



Output: a/ data: none; 

b/ status. 
For the following functions in the UC which provide MACs, the VERIFY MAC function is applicable: 

- READ BINARY STAMPED; 

- READ RECORD STAMPED. 

The cryptogram shall be in accordance with TS 101 206-3 [2]. The key indicated in the command header of the 
VERIFY MAC function, shall be the same as the one used to compute the MAC in the UC. 



8.3.2 UPDATE (SM) 



The purpose of this function is to update information in the SM. Only after verification of a MAC performed in the UC 
with a READ RECORD STAMPED, shall the information be updated. The SM shall check if the indicated key is 
allowed to perform this function. 



1 Command header 




Para meters of the READ RECORD STAMPED command 

1 


1 
ilNS 


1 
PI 1 P2 1 Le 1 Data i MAC | 


UPDA-IE(SM) 



Figure 13: Structure of UPDATE (SM) 

Pre-conditions: the challenge used shall be obtained from the SM using an ASK PARAMETER function and 
transmitted to the UC using a GIVE RANDOM; 

the keyset shall be selected using the SELECT KEYSET function. The relevant key file shall be 
the one containing the keys after diversification; 



Input: 



the file to be updated in the SM shall be selected. 

a/ command header/trailer(UPDATE (SM)); 

b/ Key number (included in the command header); 

c/ data (parameters of the previous READ RECORD STAMPED (UC) command/response). 
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Output: 



Table 15: Data field of the UPDATE (SM) command 



Bytes 


Description 


Length 


1 


INS byte of the previous READ RECORD STAMPED command 
sent to the UC (Coded according to TS 101 206-3 [2]) 


1 byte 


2 


PI of the previous READ RECORD STAIVIPED command sent 
to the UC (coded according to TS 101 206-3 [2]) 


1 byte 


3 


P2 of the previous READ RECORD STAIVIPED command sent 
to the UC (coded according to TS 101 206-3 [2]) 


1 byte 


4 


The Lg of the previous READ RECORD STAMPED command 
sent to the UC (Coded according to TS 101 206-3 [2]) 


1 byte 


5 - (4+X) 


The data field of the previous READ RECORD STAMPED 
response sent by the UC (Coded according to TS 101 206-3 [2]) 


X bytes 



a/ data: none; 
b/ status. 



The MAC shall be in accordance with TS 101 206-3 [2]. The key indicated in the command header of the UPDATE 
(SM) function, shall be the same as the one used to compute the MAC by the READ RECORD STAMPED function in 
the UC. 



8.3.3 INCREASE (SM) 

The purpose of this function is to increase a balance in the SM by exactly the same amount that was decreased before 
from the counter value in a valid UC in the same transaction. The SM shall check if the indicated key is allowed to 
perform this function. 





Para meters of the DECREASE STAMPED command 

1 


Trailer i 


1 

1 Command header 1 INS 1 PI 


1 

1 P2 1 Le 1 Data i MAC i 


INCREASE(SM) 



Figure 14: Structure of INCREASE (SIVI) 

Pre-conditions: the challenge used shall be obtained from the SM using an ASK PARAMETER function and 
transmitted to the UC using a GIVE RANDOM; 

the keyset shall be selected using the SELECT KEYSET function. The relevant key file shall be 
the one containing the keys after diversification; 

the file to be increased in the SM shall be selected; 

this function follows a DECREASE STAMPED of the UC and the data (value deducted) decreased 
in the UC shall be used as data (value added) increased in the SM. 



Input: 



a/ command header/trailer (INCREASE (SM)); 

b/ Key number (included in the command header); 

c/ data (parameters of the previous DECREASE STAMPED (UC) command/response). 
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Table 16: Data field of the INCREASE (SM) command 



Bytes 


Description 


Length 


1 


INS byte of the previous DECREASED STAMPED sent to the 
UC (Coded according to TS 101 206-3 [2]) 


1 byte 


2 


P1 of the previous DECREASED STAMPED sent to the UC 
(coded according to TS 101 206-3 [2]) 


1 byte 


3 


P2 of the previous DECREASED STAMPED sent to the UC 
(coded according to TS 101 206-3 [2]) 


1 byte 


4 


The Lg of the previous DECREASED STAMPED sent to the UC 
(Coded according to TS 101 206-3 [2]) 


1 byte 


5 - (4+X) 


The data field of the previous DECREASE STAMPED response 
sent by the UC (Coded according to TS 101 206-3 [2]) 


X bytes 



Output: 



a/ data: none; 
b/ status. 



The MAC shall be in accordance with TS 101 206-3 [2]. The key indicated in command header of the INCREASE (SM) 
function, shall be the same as the one used to compute the MAC by the DECREASE STAMPED function in the UC. 

8.3.4 VERIFY CRYPTOGRAM 

The purpose of this function is to authenticate an application in the user card by verifying the cryptogram performed in 
the UC after an INTERNAL AUTHENTICATION (INT.AUTH) command. 



Command header 



Cryptogram 



Trailer 



VERIFY C PYPTDG RAM 



Figure 15: Structure of VERIFY CRYPTOGRAIVI 

Pre-conditions: the challenge used shall be generated by the SM after an ASK PARAMETER command and 
transmitted to the UC using an INTERNAL AUTHENTICATION command; 

the keyset shall be selected using the SELECT KEYSET function. The relevant key file shall be 
the one containing the keys after diversification. 



Input: 



a/ command header/trailer (VERIFY CRYPTOGRAM); 

b/ key number (indicated in the command header if SM is an IC card). 

c/ cryptogram. 

Table 17: Data field of the VERIFY CRYPTOGRAM command 



Bytes 


Description 


Length 


1 -X 


Crytpogram 


X bytes 



Output: 



a/ data: none; 
b/ status. 
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The cryptogram shall be in accordance with TS 101 206-3 [2]. The key indicated in the command header of the 
VERIFY CRYPTOGRAM function, shall be the same as the one used to compute the cryptogram in the UC. 

8.4 Functions for downloading of keys from the SIVI to the UC 

The functionality for downloading of keys from the SM to the UC for a SM being an IC card is described in annex A, 
clause A.7. 

8.5 Functionality on SIVI - EW interface 

If the SM is an IC card, the functions and the set of commands according to TS 101 206-3 [2] shall be used to handle the 
management of SM files belonging to telecom applications specified by ETSI. 

In any other case, the functionality of the SM - EW interface is out of the scope of the present document. 

NOTE: It is strongly recommended that the integrity of functions and commands is maintained. 



29 



TS101 206-7 V1 .2.1 (1998-01) 



8.6 Linking functions with keys 



A linking of functions to key numbers within the SM is needed which limits the use of any function to only those key 
numbers which this function is allowed to use. 

The SM shall handle a set of information in order to link each key to its respective functions: 

relevant key qualifier; 

Table 18: Key qualifier 



File level 


Relevant key qualifier 


MF 


IC card manufacturing references, card personalizer ID, 
key file version, EFkfy type 


DF (application level) 


AID, key file version, EFkfy type 


DF (under application level) 


Proprietary part of AID, key file version, EFkfy fype 



master key; 

algorithm ID; 

algorithm; 

diversified key; 

functions allowed to use this key; 

access conditions to change this set of information. 

Details of how this linking is managed by the SM is out of the scope of the present document. 

NOTE: A SM contains all secrets to compute cryptograms normally coming from a UC. Theoretically a fraudulent 
terminal can bypass the presence of a valid UC by asking the SM to compute all cryptograms as coming 
from a UC and presenting them to the SM for verification. 

8.7 Limitations of the usage of keys 

The usage of keys for the following functions shall be restricted by the SM: 

- COMPUTE MAC (EXECUTE); 

- COMPUTE MAC (DECREASE); 

- VERIFY MAC (READ BINARY STAMPED); 

- VERIFY MAC (READ RECORD STAMPED); 

- VERIFY CRYPTOGRAM (INTERNAL AUTHENTICATION); 

- UPDATE (SM); 

- INCREASE (SM); 

- DECREASE (SM); 

- COMPUTE MAC EW. 



A more detailed description of the functionality in case of a SM being an IC card is given in annex A. 
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Data elements 



Application independent data elements and those data elements which are necessary to support EN 726-5 [3] are 
described in the following subclauses. 



9.1 



Data for SM identification 



9.1.1 SIVIidentifier 

Purpose: data element to uniquely identify the SM (device). 

Status: mandatory for auto billing application, see EN 726-5 [3]. 

Format: 4 bytes. 

Contents: register, maintained by ISO/IEC according to ISO/IEC 10202-4 [5]. 



9.2 



UC data 



This is an informative listing of related data elements in the UC and on its interface and does not define requirements for 
the storage or handling of this data in the SM. 

9.2.1 IC serial number of user card 

Purpose: data element to uniquely identify the IC within each UC. 

Status: mandatory. 

Format: 4 byte binary. 

Contents: at the discretion of the IC manufacturer. 

stored in the EFj^c of the UC, see TS 101 206-3 [2]. 

9.2.2 Application Expiry date 

Purpose: data element to define on which date the application ceases to be valid for use. 

Status: mandatory. 

Format: 3 bytes Binary Coded Decimal (BCD) in the format YYMMDD. 

Contents: for the prepayment application the expiry date is stored in EFp^y of the UC, see EN 726-5 [3]; 

for the auto billing application the expiry date is stored in EF^ypo °f ^^^ UC, see EN 726-5 [3]. 

9.2.3 Application Identifier (AID) 

Purpose: data element to uniquely identify the application and the relevant keyset. 

Status: optional, but strongly recommended. 

Format: 1-16 bytes binary (see ISO/IEC 7816-5 [4]). 

Contents: according to ISO/IEC 78 16-5 [4]. 
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9.2.4 

Purpose: 

Status: 

Format: 

Contents: 

9.2.5 

Purpose: 

Status: 
Format: 

Contents: 



Key file version 

data element to uniquely identify the version of a key file within an appUcation. 

mandatory. 

1 byte binary coded. 

keyset version number, stored in a UC in EFj^y op/ MAN according to TS 101 206-3 [2], 
in a SM being an IC card in EFj^y op/ MAN according to the present document. 

Algoritlnm identifier 

data element linked to any key to uniquely identify the algorithm and its parameters to perform a 
cryptographic calculation. 

mandatory. 

1 byte binary, stored in a UC in EFj^y op/ MAN according to EN 726-3 [3], subclauses 10.6 and 
10.7, in SM being an IC card in EFj^gy op/ MAN according to the present document. 

according to a register to be established and maintained. 



9.2.6 Amount 

Purpose: data element containing the amount deducted. 

Status: mandatory for prepayment application: 

Deducted from EF^jyjQyj^j of UC and SM, see EN 726-5 [3] subclause 5.4.3. 

Format: 3 bytes binary coded. 

Contents: amount to be deducted. 



9.2.7 Value 

Purpose: data element containing the new counter value of the specific application. 

Status: mandatory for prepayment application: 

Deducted from EF^mount of UC and SM, see EN 726-5 [3]. 

Format: I +X bytes binary coded. 

Contents: length of the counter value, counter value. 



9.2.8 Type of units 

Purpose: data element to indicate the kind of units and the equivalent of one unit of the counter of 

EFamount UC. 

Status: mandatory for prepayment application: 

Stored in EFp^y of UC, see EN 726-5 [3]. 

Format: 4 bytes BCD. 

Contents: Telecom unit, equivalence of one unit. 

Coding: Telecom unit 3 bytes according to ISO 4217 [6] and EN 726-5 [3]. 
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9.3 Status conditions returned by the SIVI 

For consistency of an application using different types of SM the responses to different functions shall have the same 
meaning. 

9.3.1 Functions versus possible status responses 

In this subclause only responses concerning the additional functions for the SM are defined. 
For functions used in a SM described in TS 101 206-3 [2], refer to relevant responses there. 
Tables 16 and 17 show for each supplementary function the possible status conditions returned (marked by *). 

Table 19: Status responses 





Security Status 




Memory 
Status 


Functions 


9 
8 
A 

D 


9 
8 

02 


9 
8 



4 


9 
8 


8 


9 
8 

1 



9 
8 

3 

5 


9 
8 

4 



9 
8 

5 





9 
2 

X 


9 
2 

1 



9 
2 

2 



9 
2 

4 



SELECT KEYSET 
DIVERSIFY KEYS 
ASK PARAMETER 
COMPUTE CRYPTOGRAM 
VERIFY CRYPTOGRAM 
COMPUTE MAC 
VERIFY MAC 
UPDATE (SM) 
INCREASE (SM) 
DECREASE (SM) 
COMPUTE LOAD KEY 
COMPUTE MAC EW 


* 
* 

* 
* 

* 
* 


* 


* 


- 


* 

* 
* 

* 
* 


* 

* 
* 

* 
* 


- 


- 




* 
* 


- 


- 


* 
* 

* 
* 

* 
* 



The status condition "Command out of sequence" ('98 AD') returned by the SM can appear after any command 
depending on the application and on the implementation of the sequence control. 

Table 20: Status response 





Reference 






Application 




OK 




Status 




1 


ndependent 
Errors 






Functions 


9 


9 


9 


9 




6 


6 


6 


6 


6 




9 


9 




4 


4 


4 


4 




E 


D 


F 


B 


7 







F 


















X 


X 


X 


X 


X 







X 







2 


4 


8 




X 


X 


X 


X 


X 







X 


SELECT KEYSET 


- 


- 


* 


- 




* 


* 


* 


** 


* 




* 


- 


DIVERSIFY KEYS 


* 


- 


- 


* 




* 


* 


* 


** 


* 




* 


- 


ASK PARAMETER 


- 


* 


- 


- 




* 


* 


* 


** 


* 




* 


- 


COMPUTE CRYPTOGRAM 


- 


- 


- 


- 




* 


* 


* 


** 


* 




* 


* 


VERIFY CRYPTOGRAM 


- 


- 


- 


- 




* 


* 


* 


** 


* 




* 


- 


COMPUTE MAC 


- 


- 


- 


- 




* 


* 


* 


* 


* 




* 


* 


VERIFY MAC 


- 


- 


- 


- 




* 


* 


* 


* 


* 




* 


- 


UPDATE (SM) 


* 


- 


- 


* 




* 


* 


* 




* 




* 


- 


INCREASE (SM) 


* 


- 


- 


* 




* 


* 


* 




* 




* 


* 


DECREASE (SM) 


* 


- 


- 


* 




* 


* 


* 




* 




* 


* 


COMPUTE LOAD KEY 


- 


- 


- 


- 




* 


* 


* 




* 




* 


* 


COMPUTE MAC EW 


- 


- 


- 


- 




* 


* 


* 




* 




* 


* 
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9.3.1.1 



Security management 



Table 21 : Security management 



SW1 


SW2 


Error description 


'98' 


'02' 


- No Card Holder Verification information (CHV) and/or key defined 

- There were no AC to be fulfilled for this DF 


'98' 


'04' 


- AC not fulfilled 

- Wrong cryptogram verification 

- Unsuccessful CHV verification but verify CHV mechanism still possible (number of 
false consecutive verifications < N) 

- Unsuccessful UNBLOCK CHV verification but verify UNBLOCK CHV mechanism still 
possible (number of false consecutive verifications < 10) 


'98' 


'08' 


- In contradiction with CHV status 

- The CHV protecting the file at the CP is not blocked 


'98' 


'10' 


- In contradiction with the invalidation status 


'98' 


'35' 


- No ASK RANDOM/GIVE RANDOM before 


'98' 


'40' 


- Unsuccessful CHV verification, verify CHV mechanism no longer possible (number of 
false consecutive verifications > N) 

- Unsuccessful UNBLOCK CHV verification, verify UNBLOCK CHV mechanism no 
longer possible (number of false consecutive verifications > 10 ) 


'98' 


'50' 


- Increase/Decrease cannot be performed 
Maximum/minimum value reached) 


'98' 


'AD' 


- Command out of sequence 



9.3.1 .2 Memory management 

Table 22: Memory management 



SW1 


SW2 


Error description 


'92' 


'OX' 


- Update successful but after using an internal retry routine x times 


'92' 


'10' 


- Insufficient memory space available 


'92' 


'20' 


- File ID is already existing in this parent file (MF, DF) 


'92' 


'40' 


- Memory problem 



9.3.1.3 



Referencing management 



Table 23: Referencing management 



SW1 


SW2 


Error management 


'94' 


'00' 


- No EF selected as current 

- EF not selected 


'94' 


'02' 


- Out of range (invalid address) 


'94' 


'04' 


- File ID not found 

- Record not found (see note) 

- Pattern not found 


'94' 


'08' 


- Current file is inconsistent with the command 



NOTE: The use of 94 04 for record not found is not recommended for future applications, 94 02 should be used 
instead. 
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9.3.1.4 



Application independent errors 



Table 24: Application independent errors 



SW1 


SW2 


Error description 


'6E' 


'XX' 


- Wrong instruction class given in tine command 


'6D' 


'XX' 


- Unknown instruction code given in tine command 


'6F 


'XX' 


- Teclnnical problem with no diagnostic given 
(command aborted) 


'6B' 


'XX' 


- Incorrect parameters P1 or P2 


'67' 


'XX' 


- Incorrect parameter P3 



9.3.1 .5 Responses to commands which are correctly executed or supporting 

chaining mechanism 



Table 25: Responses to commands which are correctly executed or supporting chaining mechanism 



SW1 


SW2 


Error description 


'90' 


'00' 


- Normal ending (ACK) of the command 


'9F' 


'XX' 


- Length 'XX' of the response data 
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Annex A (normative): 

The case of a SM in the form of an IC card 



A.1 Purpose 



This annex describes the SM in the form of an IC card for a system which handles user cards in accordance with 
TS 101 206-3 [2]. The following limitations are given: 

a) the SM handles one and only one terminal (the SM handles derived keys based on symmetric algorithms only); 

b) the SM supports the minimum subset of functionality described in the main part of the present document. 
Other configurations are out of the scope of this annex. 

A.2 General requirements of a SIVI in the form of an 
IC card 

Physical characteristics and electronic signals and transmission protocols shall be in accordance with TS 101 206-3 [2]. 
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A.3 Card architecture 



AC 



MF 



AC 



DF2 



AC 



DPI 



AC 



EFKEYMAN 
(SM) 



AC 



EFKEYMAN 
(SM) 



AC 



EFKEYMAN 
(UC-1) 



I 



AC 



EFKEYMAN 
(UC-2) 



T 



"AU" 



EFDIK 1 
(UC) 



I 



AC 



EFDIK 2 
(UC) 



1 



AC 



EFA MOUNT 



AC 



EFKEYOP 
(SM) 



AC 



EFKEYOP 
(SM) 



1 



AC 



EFKEY_OP 
(UC-1) 



1 



AC 



EFKEYO P 
(UC-2) 



AC 



EFKEY TABLE 



AC 



EFKEY TABLE 



AC 



EFDIR 

(SM) 



AC 



EFICC 
(SM) 



Keys used for 
functions acting 
in tine SJVl 



|viasterl<eys 
Key version 1 



|viasterl<eys 
Key version 2 

Diversified 
l<eysused for 
functions acting 
in tine usercard 
for management 
purposes (IVIAN) 
and operational 
purposes (OP) 



Figure A.I : An example of key architecture for a SIV! (IC card) 

For functions performed on the SM by the management system, fixed keys are used to fulfil AC as described in 

TS 101 206-3 [2]. For functions to be performed on the UC, the SM uses diversified keys as described in the present 

document. 
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A. 4 Description of files 
A.4.1 IVIaster file 

Status: mandatory. 

Reference: see ISO/IEC 7816-4 [4]. 



A.4.2 EF,oc 



Status: 




mandatory. 


Contains 




a SM identifier. 


Reference 




see TS 101 206-3 [2], subclause 10.4, 


A.4.3 


^■"dir 


Status: 




optional, but recommended. 


Reference 




see TS 101 206-3 [2] subclause 6.3. 


A.4.4 


ER 


rPV MAM (SM) 



Purpose: see TS 101 206-3 [2] . 

Status: mandatory. 

Reference: see TS 101 206-3 [2] subclause 10.6. 

A.4.5 EFkby.op (SM) 

Purpose: see TS 101 206-3 [2]. 

Status: optional. 

Reference: see TS 101 206-3 [2] subclause 10.7. 

A.4.6 DFx 

Status: at least one DF mandatory. 

Reference: see TS 101 206-3 [2] subclause 9.2.3. 
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A.4.7 Files containing master keys: EFkey_man/op (UC)X 

These key files contain the master keys corresponding to the keyset version X in the UC. 

Table A.1:EFkey MAN (UC) 



File ID: '20 XX' EFkfy mam (UC) (note) 


Optional 


Type of file: '00' (Transparent EF) 


AC: 

LOAD KEY FILEUPDATE PROPRO 
INVALIDATE NEV 
REHABILITATE NEV 


Bytes 


Description 


Length 


1 


Keyset version 


1 byte 


2 


Length of key (X bytes) 


1 byte 


3 


Algorithm ID for key 


1 byte 


4-3 + X 


KeyO 


X bytes 


4 + X 


Length of key 1 


1 byte 


etc. 






NOTE: Key file number is indicated by 'XX'. 
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Table A.2: EFkey op (UC) 



File ID: '21 YY' EFkfy op (UC) (note 1) Mandatory 


Type of file: '00' (Transparent EF) 


AC: 

LOAD KEY FILEUPDATE PRO (note 2)PR0 (note 2) 
INVALIDATE PRO (note 2) 
REHABILITATE PRO (note 2) 


Bytes 


Description 


Length 


1 


Keyset version 


1 byte 


2 


Length of key (X bytes) 


1 byte 


3 


Algorithm ID for key 


1 byte 


4-3 + X 


KeyO 


X bytes 


4 + X 


Length of key 1 


1 byte 


etc. 






NOTE 1 : Key file number is indicated by 'YY'. 

NOTE 2: It is up to the SM provider to link the function to any of the keys of the relevant 
EFkeY_MAN (SM)- 



End of file is indicated by the key length being 0. 

The structure of this file has to be the mirror of the relevant EFj^y fils of the UC, even if some keys are not used in SM. 

For those master keys which are not available in the SM, the coding shall be according to table A. 3. 

Table A.3: Coding of master keys which are not available (EFkey man CJC) °'' ^^key op (UC)) 



Bytes 


Description 


Length 








n 


Length of key 1 ('XX' bytes) 


1 byte 


(n+1) 


Algorithm ID for key 1 ('FF', see note) 


1 byte 


(n+2)-(n+1 + 
XX) 


KeyX 


XX bytes 








NOTE: Algorithm ID = 'FF' indicates that the content is not a valid master key and use of this 
master key shall never be allowed. 
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A.4.8 File for linking keys to functions: EFkeytable 

This file contains a table linking the keys of EFj^y op (UC) or EFj^gy man (UC) to functions and is the responsibility 
of the SM provider or authority delegated by him. For each EF^jj^ (OP or MAN) one EFkeytable shall exist. 
Only the relevant key may be used for those functions (see subclause 8.7) which are linked in the EFkeytable. 



Table A.4: EFkeytable 



File ID: '02 XX' EFkeytable (note) Mandatory 


Type of file: '01 ' (EF with a linear fixed structure) 


AC: 

READ NEV 
CREATE.. .EXECUTE PRO 
UPDATE NEV 
WRITE NEV 
INVALIDATE NEV 
REHABILITATE NEV 


Bytes 


Description 


Length 


1 


INS of the SM command 


Ibyte 


2 


INS of the UC command which is Included in the cryptogram 


1 byte 


3 


Key number linked to the SM command 


1 byte 


4-5 


File ID of the relevant file in the SM 


2 bytes 


6 


INS of the SM command 


1 byte 


7 


INS of the UC command which is included in the cryptogram 


1 byte 


8 


Key number linked to the SM command 


1 byte 


9-10 


File ID of the relevant file in the SM 


2 bytes 








NOTE: 'XX' = '00' means EFkeytable (MAN). 
'XX' = '01' means EFkeytable (OP). 
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A.4.9 EF 



AMOUNT 



(SM) 



This file contains the counter value which may only be changed by the INCREASE (SM) or by DECREASE (SM) 
functions. 



Table: A.5: EF 



AMOUNT 



(SM) 



File ID: '1 2 XX' EFamoi int (SM) (note 1 ) Optional 


Type of file: '03' (Cyclic EF) 


AC: 

READ PRO (note 2) 
CREATE.. .EXECUTE PRO (note 2) 
DECREASE PRO (notes 2 and 3) 
INCREASE PRO (notes 2 and 3) 
INVALIDATE PRO (note 2) 
REHABILITATE PRO (note 3) 


Bytes 


Description 


Length 


1 -3 


Counter value 


3 bytes 


NOTE 1 : 'XX' is equal to '00' except when there is more than one EF^^youNj (SM) under the 
same DF. 

NOTE 2: It is up to the security module provider to link the function to any of the keys of the 
relevant EF(^ey MAnSM. 

NOTE 3: ACs INCREASE/DECREASE replace the ACs UPDATE/WRITE like in a UC, as 
described in TS 101 206-3 [2]. 



Bytes 1 - 3 are represented in HEX notation. 
See also EN 726-5 [3], subclause 5.4.3. 
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A.4.10 Files containing diversified keys: 
EFdik op(UC) and EFd.kman (UC) 



These Keyfiles contain the diversified keys derived fi^om the master keys stored in EFj^y op (UC) / EFj^y man (UC) 
of the SM corresponding to the keyset version x in the UC. 



Table A.6: EF 



DIK MAN 



(UC) 



File ID: '1 00' EFpiK mam (UC) Optional 


Type of file: '00' (Transparent EF) 


AC: 

LOAD KEY FILE 

UPDATE NEVNEV (note 2) 
INVALIDATE NEV 
REHABILITATE NEV 


Bytes 


Description 


Length 


1 


Keyset version 


1 byte 


2 


Length of key (X bytes) 


1 byte 


3 


Algorithm ID for l<ey 


1 byte 


4-3 + X 


KeyO 


X bytes 


4 + X 


Length of key 1 


1 byte 








NOTE 1 : It is up to the SM provider to linl< the function to any of the l<eys of the relevant 
EFkey_MAN (SM). 

NOTE 2: The only function possible after the creation of this file shall be an internal update 
using the function DIVERSIFY KEYSET. 
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Table A.7: EF 



DIK OP 



(UC) 



File ID: '1 1 00' EFpiK np (UC) Mandatory 


Type of file: '00' (Transparent EF) 


AC: 

UPDATE NEV (note 2) 
LOAD KEY FILE NEV 
INVALIDATE 

REHABILITATE NEV 

NEV 


Bytes 


Description 


Length 


1 


Keyset version 


1 byte 


2 


Length of key (X bytes) 


1 byte 


3 


Algorithm ID for key 


1 byte 


4-3 + X 


KeyO 


X bytes 


4 + X 


Length of key 1 


1 byte 








NOTE 1 : It is up to the SM provider to link the function to any of the keys of the relevant 
EFkey_MAnSM. 

NOTE 2: The only function possible after the creation of this file shall be an internal update 
using the function DIVERSIFY KEYSET. 



If length of key is '00' this indicates end of file. 

If length of key is '01' this indicates that this key is not used. The following byte indicates length of next key. 

Even if master keys are not present in this SM, all keys in the UC shall be included in the table up to the highest key 
number stored in the UC. 

For those master keys which are not available the coding shall be according to table A. 3. 
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A. 5 Commands 



A.5.1 General remarks 

If the SM is an IC card, the commands described in TS 101 206-3 [2] clause 8 are acting on MF, DFs and EFs. 
Additional commands are described in the following subclauses. 

In the case the SM is an IC card the command header consists of the CLA; INS, PI, P2 and L,, elements and the trailer 
consists of the L^ element, they are coded as specified hereafter for the commands involved. 



A.5.2 Additional commands 



Table A.8: Coding of commands 



Command 


INS 


PI 


P2 


SELECT KEYSET 


'50' 


'00' 


'00' 


DIVERSIFY KEYSET 


'52' 


EFj^jj^ number 


'00' 


ASK PARAMETER 


'54' 


Type 


'00' 


COMPUTE LOAD KEY 


'70' 


EFj-jjj^ number 


Key number 


COMPUTE CRYPTOGRAM 


56' 


'00' 


Key number 


VERIFY CRYPTOGRAM 


'58' 


'00' 


Key number 


COMPUTE MAC 


'8A' 


'00' 


Key number 


VERIFY MAC 


'8E' 


'00' 


Key number 


UPDATE (SM) 


'5A' 


'00' 


Key number 


INCREASE (SM) 


'5C' 


'00' 


Key number 


DECREASE (SM) 


'5E' 


'00' 


Key number 



A.5.2.1 SELECT KEYSET 

Table A.9: Coding of the SELECT KEYSET command 



CLA 


As defined in TS 101 206-3 [2] subclause 9.2 . 


INS 


'50 


P1 


'00' 


P2 


'00' 


Lp field 


Length of the data field. 


Data field 


Key qualifier. 


Lg field 


Empty. 



Table A.10: Coding of the data field of the SELECT KEYSET command (in case of a lUlF) 



Bytes 


Description 


Length 


1 -4 


IC card manufacturing references (coded according to 
TS101 206-3 [2]) 


4 bytes 


5 


Card personalizer ID (coded according to TS 101 206-3 [2]) 


1 byte 


6-7 


File ID of the EF^fy- 


2 bytes 


8 


Keyfile version (coded according to TS 101 206-3 [2]) 


1 byte 
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Table A.1 1 : Coding of the data field of the SELECT KEYSET command (in case of a DF) 



Bytes 


Description 


Length 


1 -X 


AID (coded according to TS 101 206-3 [2]) 


1 - 16 bytes 


{X+1)-(X+2) 


File ID of the EFkfy 


2 bytes 


X+3 


Keyfile version (coded according to TS 101 206-3 [2]) 


1 byte 



A.5.2.2 DIVERSIFY KEYSET 

Table A.12: Coding of the DIVERSIFY KEYSET command 



CLA 


As defined in TS 101 206-3 [2] subclause 9.2. 


INS 


'52' 


PI 


EFp|(^ number. 


P2 


'00' 


Lp field 


Length of the data field. 


Data field 


Diversification data. 


Le field 


Empty. 



Coding of EFqjj^ number (PI): 

a) 'OO'EFqjj^ number 1: used to temporarily store relevant keys, diversified from selected master keyset, to 
perform the following function. 

b) 'OI'EFqjj^ number 2: used to temporarily store the diversified keyset to be down loaded. 

Table A.13: Coding of the data field of the DIVERSIFY KEYSET command 



Bytes 


Description 


Length 


1 


Algorithm ID for diversification 


1 byte 


2-X 


Diversification data 


1 - 16 bytes 


NOTE: This command includes the functionality to provide the contents of the EFqd^ 
(keyfile version, key length, algorithm identifier and diversified keys). 



For coding of algorithm ID see TS 101 206-3 [2] subclause 7.6.5 
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A.5.3 Commands handling parameters for cryptography 

A.5.3.1 ASK PARAMETER 

Table A.I 4: Coding of the ASK PARAMETER command 



CLA 


As defined in TS 101 206-3 [2] subclause 9.2. 


INS 


'54' 


P1 


Type. 


P2 


'00' 


Lc field 


Empty. 


Data field 


Empty. 


Lg field 


Maximum lengtfi of data expected in response. 



Coding of types (PI): 

a) '00' challenge (random number); 

b) 'Ol'challenge (counter related to the keyset containing masterkeys selected before. 

NOTE: "Ask Parameter" triggers the modification of the counter. 

In case there is no counter linked to the selected keyset, back tracking mechanism to the next existing counter at higher 
level shall be used. 

Table A.15: Coding of the ASK PARAMETER response 



Bytes 


Description 


Length 


1 -X 


Challenge 


X bytes 


NOTE: If the algorithm TESA 7 is used, the length of the challenge Is fixed to 8 bytes. 



A.5.4 Commands to compute a cryptogram or MAC 

Mechanism to create and link counters have to be offered by the operating system. 
Implementation is out of scope of the present document. 

A.5.4.1 COMPUTE LOAD KEY 

Table A.I 6: Coding of the COMPUTE LOAD KEY command 



CLA 


As defined in TS 101 206-3 [2] subclause 9.2. 


INS 


'70' 


PI 


EFqii^ number. 


P2 


Key number. 


Lc field 


Length of the data field. 


Data field 


Data sent to the SM. 


Lg field 


Maximum length of data expected in response. 



Coding of EFqjj^ number (PI): 

'OO'EFjjjj^ number 1; (containing div. keys of keyset known by the user card) 

For computation of response relevant key(s) of EFdiki, have to be used. 

'Ol'EFj-jjj^ number 2. (containing div. keys of new keyset). 
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Table A.I 7: Coding of the data field of the COMPUTE LOAD KEY command 



Bytes 


Description 


Length 


1 


'D8' (Coded according to TS 101 206-3 [2]) 


1 byte 


2 


EFkfy type(coded according to TS 101 206-3 [2]) 


1 byte 


3 


Key number (coded according to TS 101 206-3 [2]) 


1 byte 


4 


Lp of the command sent to the UC (coded according to TS 101 206-3 [2]) 


1 byte 


5 


Key file version (only present if key number 0) 


1 byte 


6 


Key length 


1 byte 


7 


Algorithm identifier 


1 byte 


NOTE: The SM has to check internally that key number, key length, key version and algorithm ID are 
consistent with the contents of the relevant EFj^^y (UC). 



Table A.I 8: Coding of the COIVIPUTE LOAD KEY response 



Bytes 


Description 


Length 


1 -16 


Enciphered key 


1 6 bytes 


17-24 


MAC 


8 bytes 



A.5.4.2 COMPUTE MAC 



Table A.19: Coding of the COIVIPUTE MAC command 



CLA 


As defined in TS 101 206-3 [2] subclause 9.2. 


INS 


'8A' 


PI 


'00' 


P2 


Key number. 


Lp field 


Length of the data field. 


Data field 


Data sent to the SM. 


Lg field 


Maximum length of data expected in response. 



Table A.20: Coding of the data field of the COMPUTE MAC command 



Bytes 


Description 


Length 


1 


INS byte of the following command sent to the UC 
(Coded according to TS 101 206-3 [2]) 


1 byte 


2 


PI of the following command sent to the UC 
(coded according to TS 101 206-3 [2]) 


1 byte 


3 


P2 of the following command sent to the UC 
(coded according to TS 101 206-3 [2]) 


1 byte 


4 


L^ of the following command sent to the UC 
(coded according to TS 101 206-3 [2]) 


1 byte 


5 - (4-^X) 


The data field of the following command sent to the UC 
(Coded according to TS 101 206-3 [2]) 


X bytes 



Table A.21 : Coding of the COMPUTE MAC response 



Bytes 


Description 


Length 


1 -X 


MAC 


X bytes 



The data field of the COMPUTE MAC contains the data necessary to compute the MAC used in the following command 
sent to the UC. A list of all the functions for which a MAC has to be provided by the use of COMPUTE MAC command 
is given in subclause 8.2. 
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A.5.4.3 COMPUTE CRYPTOGRAM 

Table A.22: Coding of the COMPUTE CRYPTOGRAM command 



CLA 


As defined in TS 101 206-3 [2] subclause 9.2. 


INS 


■56' 


P1 


■00' 


P2 


Key number. 


L(, field 


Empty. 


Data field 


Empty. 


Lg field 


IVIaximum length of data expected in response. 



Table A.23: Coding of the COMPUTE CRYPTOGRAM response 



Bytes 


Description 


Length 


1 -X 


Cryptogram 


X bytes 



A.5.4.4 COMPUTE MAC EW 



Table A.24: Coding of the COMPUTE MAC EW command 



CLA 


As defined in TS 101 206-3 [2] subclause 9.2. 


INS 


■8C^ 


PI 


■00^ 


P2 


Key number. 


Lc field 


Length of the data field. 


Data field 


Data sent to the SM. 


Lg field 


Maximum length of data expected in response. 



Table A.25: Coding of the data field of the COMPUTE MAC EW command 



Bytes 


Description 


Length 


1 


INS byte of the following command sent to the UC 
(Coded according to TS 101 206-3 [2]) 


1 byte 


2 


P1 of the following command sent to the UC 
(coded according to TS 101 206-3 [2]) 


1 byte 


3 


P2 of the following command sent to the UC 
(coded according to TS 101 206-3 [2]) 


1 byte 


4 


Lg of the following command sent to the UC 
(coded according to TS 101 206-3 [2]) 


1 byte 


5 - (4+X) 


The data field of the following command sent to the UC 
(Coded according to TS 101 206-3 [2]) 


X bytes 



Table A.26: Coding of the COMPUTE MAC response 



Bytes 


Description 


Length 


1 -X 


MAC 


X bytes 
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A.5.5 Commands to verify cryptogram or MAC 



A.5.5.1 VERIFY MAC 



Table A.27: Coding of the VERIFY MAC 



CLA 


As defined in TS 101 206-3 [2] subclause 9.2. 


INS 


'8E' 


P1 


'00' 


P2 


Key number. 


Lc field 


Length of the data field. 


Data field 


Data sent to the SM. 


Lg field 


Empty. 



Table A.28: Coding of the data field of the VERIFY MAC command 



Bytes 


Description 


Length 


1 


INS byte of the previous command sent to the UC 
(coded according to TS 101 206-3 [2]) 


1 byte 


2 


PI of the previous command sent to the UC 
(coded according to TS 101 206-3 [2]) 


1 byte 


3 


P2 of the previous command sent to the UC 
(coded according to TS 101 206-3 [2]) 


1 byte 


4 


The Lg of the previous command sent to the UC 
(coded according to TS 101 206-3 [2]) 


1 byte 


5 - (4+X) 


The data field of the previous response sent by the UC 
(coded according to TS 101 206-3 [2]) 


X bytes 



A list of all the functions for which a MAC has to be verified by the use of VERIFY MAC command is given in 
subclause 8.3.1. 



A.5.5.2 UPDATE (SM) 



Table A.29: Coding of the UPDATE (SM) command 



CLA 


As defined in TS 101 206-3 [2] subclause 9.2. 


INS 


'5A' 


PI 


'00' 


P2 


Key number. 


Lg field 


Length of the data field. 


Data field 


Data sent to the SM. 


Lg field 


Empty. 



Table A.30: Coding of the data field of the UPDATE (SM) command 



Bytes 


Description 


Length 


1 


'B6' (Coded according to TS 101 206-3 [2]) 


1 byte 


2 


Record no. (coded according to TS 101 206-3 [2]) 


1 byte 


3 


IVIode (coded according to TS 101 206-3 [2]) 


1 byte 


4 


The Lg of the data field of the previous command 
(coded according to TS 101 206-3 [2]) 


1 byte 


5 - (4-i-X) 


The data field of the previous READ RECORD STAIVIPED response 
sent by the UC (coded according to TS 101 206-3 [2]) 


X bytes 
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A.5.5.3 VERIFY CRYPTOGRAM 



Table A.31 : Coding of the VERIFY CRYPTOGRAM 



CLA 


As defined in TS 101 206-3 [2] subclause 9.2. 


INS 


'8E' 


P1 


'00' 


P2 


Key number. 


L^ field 


Length of the data field. 


Data field 


Data sent to the SM. 


Lg field 


Empty. 



Table A.32: Coding of the data field of the VERIFY CRYPTOGRAM command 



Bytes 


Description 


Length 


1 -X 


Cryptogram 


X bytes 



A.5.6 Commands to verify a MAC and compute another 



A.5.6.1 INCREASE (SM) 



Table A.33: Coding of the INCREASE (SM) command 



CLA 


As defined in TS 101 206-3 [2] subclause 9.2 


INS 


'5C' 


PI 


'00' 


P2 


Key number. 


L^ field 


Length of the data field. 


Data field 


Data sent to the SM. 


Lg field 


Maximum length of data expected in response. 



Table A.34: Coding of the data field of the INCREASE (SM) command 



Bytes 


Description 


Length 


1 


'34' (coded according to TS 101 206-3 [2]) 


1 byte 


2 


Output mode (coded according to TS 101 206-3 [2]) 


1 byte 


3 


'00' (coded according to TS 101 206-3 [2]) 


1 byte 


4 


The Lg of the data field of the previous response 
(coded according to TS 101 206-3 [2]) 


1 byte 


5 - (4-i-X) 


The data field of the previous DECREASE STAMPED 

response sent by the UC 

(coded according to TS 101 206-3 [2]) 


X bytes 
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A.5.6.2 DECREASE (SM) 



Table A.35: Coding of the DECREASE (SM) command 



CLA 


As defined in TS 101 206-3 [2] subclause 9.2. 


INS 


'5E' 


P1 


'00' 


P2 


Key number. 


L^ field 


Length of the data field. 


Data field 


Data sent to the SM. 


Lg field 


Maximum length of data expected in response. 



Table A.36: Coding of the data field of the DECREASE (SM) command 



Bytes 


Description 


Length 


1 


INS byte of the following INCREASE or INCREASE STAMPED 

command sent to the UC 

(coded according to TS 101 206-3 [2]) 


1 byte 


2 


P1 of the following INCREASE or INCREASE STAMPED 

command sent to the UC 

(coded according to TS 101 206-3 [2]) 


1 byte 


3 


P2 of the following INCREASE or INCREASE STAMPED 

command sent to the UC 

(coded according to TS 101 206-3 [2]) 


1 byte 


4 


The Lg of the previous command 
(coded according to TS 101 206-3 [2]) 


1 byte 


5 - (4+X) 


The data field of the following INCREASE or INCREASE 
STAMPED command sent to the UC 
(coded according to TS 101 206-3 [2]) 


X bytes 



Table A.37: Coding of the DECREASE (SM) response 



Bytes 


Description 


Length 


1 -X 


MAC 


X bytes 



A.6 Status conditions returned by the SIVI 

See subclause 9.3. 
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A.7 Functions for downloading of keys from SIVI to UC 

For further information see also clause B.9. 

Three different cases where keys have to be downloaded exist: 

1) Loading of keys in an empty EFj^y man i" UC. 

In this case the key used to fulfil the AC is situated in the EFj^y man ^'- '■^^ upper level. 

This means that two different sets of diversified keys (contained in two different EF^jj^) have to be available in 

the SM, one containing the key used to fulfil the AC and one containing the keys to be downloaded. 

NOTE: To load keys in an empty EFj^y-op ^^^ same scenario has to be used but the relevant key to fulfil 
the AC is located in the EFj^y man ^'- '■^^ same level. 

2) Replacing of already existing keys in the EFj^y m^n of '^^e UC (changing keyset version from n to n+1). 

In this case the key used to fulfil the AC is situated in the EFj^y m^n containing the keyset version n. 
This means that two different sets of diversified keys (contained in two different EF^jj^) have to be available in 
the SM, one containing the key used to fulfil the AC (in EFj^y ^^n ^i'^^ keyset version n) and one containing 
the keys to be downloaded (in EFj^y ^^n ^i'^^ keyset version n+1). As long as the relevant key used to fulfil 
the AC is not replaced, the relevant key of keyset version n is valid. 

3) Replacing of already existing keys in the EFj^y Qp of the UC (changing keyset version from n to n+1). 

In this case the key used to fulfil the AC is situated in the EFj^y ^^n- 

This means that two different sets of diversified keys (contained in two different EF^jj^) have to be available in 
the SM, one containing the key used to fulfil the AC (in EFj^y ^^n) '^^'^ '^^^ containing the keys to be 
downloaded (in EFj^gy Qp with keyset version n+1). 

NOTE: It is up to the operating system to manage the coexisting of the two different EFqjj^, and what kind of keys 
(OP or MAN) are contained in each of them. 

A.7.1 Loading of keys in an empty EFkey_man in UC 

a) Selection (by use of the SELECT KEYSET function) of the file at the next upper level (EFj^gy MAN (UC)) 
containing the master keys for EFj^y ^^^^ in the UC. These master keys are used to diversify the key used to 
fulfil the AC for the function LOAD KEY FILE in the UC. 

b) Diversification of the master keys and loading of the diversified keys into EF^jj^^ by the use of DIVERSIFY 
KEYSET function. 

c) Selection (by the use of SELECT KEYSET function) of the file containing the master keys used to diversify the 
keys which are going to be downloaded. 

d) Diversification of the master keys and loading of the diversified keys into EFQjf^2 by the use of DIVERSIFY 
KEYSET function. 

e) Enciphering of the key (located in EFj-,jj^2) ^^id computation of the MAC. These two operations are performed 
using the relevant key located in EFj-,jj^2 ^i^d indicated in the parameters of the function COMPUTE LOAD 
KEY. This last action has to be repeated for each of the keys to be downloaded. 
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A.7.2 Changing of already existing keys in the EFkey_man of the UC 

a) Selection (by use of the SELECT KEYSET function) of the file (EFj^y MAN (UC)) containing the master keys 
(key version n) for EFj^y MAN ^^ ^^ UC. These master keys are used to diversify the key used to fulfil the AC 
for the function LOAD KEY FILE in the UC. 

b) Diversification of the master keys and loading of the diversified keys into EF^jj^^ by the use of DIVERSIFY 
KEYSET function. 

c) Selection (by the use of SELECT KEYSET function) of the file (EFj^gy MAN (UC)) containing the master keys 
(keyset version n+1) used to diversify the keys which are going to be downloaded. 

d) Diversification of the master keys and loading of the diversified keys into EFQjf^2 by the use of DIVERSIFY 
KEYSET function. 

e) Enciphering of the key (located in EFqjj^2) ^^id computation of the MAC. These two operations are performed 
using the relevant key located in EF£,jj^2 ^^"1 indicated in the parameters of the function COMPUTE LOAD 
KEY. As long as the relevant key used to fulfil the AC is not replaced, the relevant key of keyset version n is 
valid. 

This last action has to be repeated for each of the keys to be downloaded. 

A.7.3 Changing of already existing keys in the EFkey_op of the UC 

a) Selection (by use of the SELECT KEYSET function) of the file (EFj^y MAN (UC)) containing the master keys 
for EFj^y MAN ^^ ^^ UC. These master keys are used to diversify the key used to fulfil the AC for the function 
LOAD KEY FILE in the UC. 

b) Diversification of the master keys and loading of the diversified keys into EF^jj^^ by the use of DIVERSIFY 
KEYSET function. 

c) Selection (by the use of SELECT KEYSET function) of the file (EFj^gy Qp (UC)) containing the master keys 
EFj^gy QP (keyset version n+1) used to diversify the keys which are going to be downloaded. 

d) Diversification of the master keys and loading of the diversified keys into EFQjf^2 by the use of DIVERSIFY 
KEYSET function. 

e) Enciphering of the key (located in EFj)jj^2) ^^id computation of the MAC. These two operations are performed 
using the relevant key located in EFj-,jj^2 ^^id indicated in the parameters of the function COMPUTE LOAD 
KEY. As long as the relevant key used to fulfil the AC is not replaced, the relevant key of keyset version n is 
valid. 

This last action has to be repeated for each of the keys to be downloaded. 
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Annex B (informative): 

Scenarios for SIVI in the form of an IC card 

B.1 Key diversification procedure 

The purpose of this operation is for the SM to diversify the individual keyset of the UC. The SM uses its own master key 
and the diversification data read out from the UC to perform this operation. The diversified keys can then be used by the 
SM to compute and verify cryptograms to and from the UC. 

To perform this functionahty the terminal reads out from the user card: 

Application identifier AID; 

- refer to ISO/IEC 7816-5 [4] ; 

- refer to TS 101 206-3 [2]: 

subclause 6.5: Methods of selecting a file; 

subclause 11.1: standardized applications; 

subclause 10.3: EFDIR; 
Relevant EFKEY type; 
Key version; 

- refer to TS 101 206-3 [2] subclause 9.4. 1 SELECT (response in case of EFKEY); 
Diversification data. 

Minimum set of functions of SM needed to perform this operation: 

- SELECT KEYSET; 

- DIVERSIFY KEYSET. 

Minimum set of functions of UC needed to perform this operation: 

- SELECT; 

- READ. 

Minimum set of data in UC needed to perform this operation: 
key qualifier; 
diversification data. 
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SM 


TERMINAL 


USER CARD 




SELECT EFdir 




READ EFdir 






AID 


SELECT EpQiygi-gifipgdori 




READ (diversification data) 






Diversification data 




SELECT EFkey (optional) 


Keyset version 






SELECT KEYSET 


DIVERSIFY KEYSET 







Figure B.I : Scenario for the l<eyset diversification procedure 
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B.2 Authentication of UC by the SIVI 

The purpose of this operation is to enable the SM to verify the authenticity of the UC and by doing so to ensure that the 
appHcation within the UC has been suppHed by the entitled authority. 

After implementation of the key diversification procedure (see clause B.l), a challenge is provided to the UC. 
The answer of the UC is transferred through the terminal to the SM and is checked by the SM. 
The result of this check is passed to the terminal by the SM, to be used by it for further decisions. 

Minimum set of functions of SM needed to perform this operation: 

- VERIFY CRYPTOGRAM (INTERNAL AUTHENTICATION (UC)). 
Minimum set of functions of UC needed to perform this operation: 

- ASK PARAMETER; 

- INTERNAL AUTHENTICATION. 

Minimum set of data in UC needed to perform this operation: 
key. 



SM 


TERMINAL 


USER CARD 




Key diversification procedure 
ASK PARAMETER 




Challenge 






INTERNAL AUTHENTICATION 
(challenge (UC)) 




Cryptogram 


VERIFY CRYPTOGRAM 




Status (result of verification) 









Figure B.2: Scenario for Authentication of UC by the SIVI 
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B.3 Authentication of SIVI by the UC 

The purpose of this operation is to enable the UC to verify the authenticity of the SM and the appHcation within the SM, 
and by doing so to ensure that the application within the SM has been supplied by an authority entitled to use the 
specific UC. 

After implementation of the key diversification procedure (see clause B.l), a challenge created by the UC is given to 
the SM. The answer of the SM transmitted through the terminal to the UC is checked by the UC. The result is used to 
prove the AC = AUT of the relevant file of the UC. 

Minimum set of functions of SM needed to perform this operation: 

- COMPUTE CRYPTOGRAM (EXTERNAL AUTHENTICATION (UC)); 

- GIVE RANDOM. 

Minimum set of functions of UC needed to perform this operation: 

- ASK RANDOM; 

- EXTERNAL AUTHENTICATION. 

Minimum set of data in UC needed to perform this operation: 
key. 



SM 


TERMINAL 


USER CARD 




Key diversification procedure 
ASK RANDOM 






Challenge 


GIVE RANDOIVI 






COMPUTE CRYPTOGRAM 


Cryptogram 






EXTERNAL AUTHENTICATION 
(Cryptogram (UC)) 




Authenticated if cryptogram is OK 



Figure B.3: Scenario for Authentication of SIUI by the UC 
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B.4 Compute MAC for protected mode (message 
authentication) 

The purpose of this operation is to generate a cryptogram in the SM that is needed by the terminal to use commands in 
the protected (PRO) mode of the UC. After implementation of the key diversification procedure (see clause B. 1) the 
terminal sends a command to the SM (including the header of the command to the UC) and if necessary the data that has 
to be used to compute the cryptogram. The SM checks if it is allowed to use its keys to compute the cryptogram that has 
been demanded. If the SM is allowed to use its keys, it returns the cryptogram to the terminal which uses it to built the 
command to the UC. 

Minimum set of functions of SM needed to perform this operation: 

- GIVE RANDOM; 

- COMPUTE MAC. 

Minimum set of functions of UC needed to perform this operation: 

- ASK RANDOM; 

- Command "PRO". 

Minimum set of data in UC needed to perform this operation: 
key. 



SM 


TERMINAL 


USER CARD 






Key diversification procedure 
ASK RANDOM 






Challenge 


GIVE RANDOM 


> 




COMPUTE MAC (command, 

parameters of the UC 

command) 


MAC 






COIVIMAND (see note) 




NOTE: 


See list of applicable functions in subclause 8.2.2. 





Figure B.4: Scenario for COIUIPUTE lUIAC 
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B.5 Verify MAC command 



The purpose of this operation is to verify a cryptogram in the SM. The cryptogram is a result of an internal 

authentication or the result of a stamped mode command performed in the UC. 

This operation is carried out after implementation of the key diversification procedure (see clause B.l). 

Minimum set of functions of SM needed to perform this operation: 

- ASK PARAMETER; 

- VERIFY MAC. 

Minimum set of functions of UC needed to perform this operation: 

- Command STAMPED; 

- GIVE RANDOM. 

Minimum set of data in UC needed to perform this operation: 
data read value; 
key. 



SM 


TERMINAL 


USER CARD 




Key diversification procedure 
ASK PARAMETER 




Challenge 






GIVE RANDOM 


COMMAND (See note ) 






Response, MAc, status 


VERIFY MAC (parameters of the 
previous UC command/response) 




Status (result of verification) 


> 




NOTE: See list of applicable functions in subclause 8.3.1 . 



Figure B.5: Scenario for VERIFY MAC 
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B.6 UPDATE (SM) 



The purpose of this operation is to update a record in a file of the SM using the read stamped mode of the UC. 
This operation is carried out after implementation of the key diversification procedure (see clause B. 1). 

Minimum set of functions of SM needed to perform this operation: 

- SELECT; 

- ASK PARAMETER; 

- UPDATE (SM). 

Minimum set of functions of UC needed to perform this operation: 

- SELECT; 

- READ STAMPED; 

- GIVE RANDOM. 

Minimum set of data in UC needed to perform this operation: 
data read value; 
key. 
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SM 


TERMINAL 


USER CARD 




Key diversification procedure 






ASK PARAMETER 


Challenge 






GIVE RANDOM 


SELECT (file) 




READ RECORD STAMPED 






Data, MAC, status 


SELECT (file) 






UPDATE (SM) (parameters of the 
previous READ RECORD 
STAMPED (UC) 
command/response) 


If verification of the IVIAC is OK, 
then update the cyclic file with the 
data given in UPDATE (SM) 

Status 









Figure B.6: Scenario for UPDATE (SIUI) 
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B.7 Secure transfer of units from UC to SM 

The purpose of this operation is to add an amount to a balance in the SM, only if it was previously decreased from a 

counter value in a valid UC. 

This operation is carried out after implementation of the key diversification procedure (see clause B. 1). 

Minimum set of functions of SM needed to perform this operation: 

- ASK PARAMETER; 

- SELECT; 

- INCREASE (SM). 

Minimum set of functions of UC needed to perform this operation: 

- SELECT; 

- GIVE RANDOM; 

- DECREASE STAMPED. 

Minimum set of data in UC needed to perform this operation: 

counter value; 
key. 



SM 


TERMINAL 


USER CARD 




Key diversification procedure 
ASK PARAMETER 




Challenge 






GIVE RANDOM 


SELECT (file) 




DECREASE STAMPED 






Data, MAC, status 


SELECT (cyclic file) 






INCREASE (SM) (parameters of the 

previous DECREASE STAMPED 

(UC) command/response) 


Status 









Figure B.7: Scenario for INCREASE (SM) 
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B.8 Secure transfer of units from SM to UC (reload) 

The purpose of this operation is to add an amount to a counter value in a vaHd UC, only if it was previously decreased 

from a balance in an authorized SM. 

This operation is carried out after implementation of the key diversification procedure (see clause B.l). 

Minimum set of functions of SM needed to perform this operation: 

- GIVE RANDOM; 

- SELECT; 

- DECREASE (SM). 

Minimum set of functions of UC needed to perform this operation: 

- INCREASE; 

- ASK RANDOM. 

Minimum set of data in UC needed to perform this operation: 
data read value; 
key. 



SM 


TERMINAL 


USER CARD 




Key diversification procedure 
ASK RANDOM 






Challenge 


GIVE RANDOM 






SELECT (cyclic file) 




DECREASE (SM) (parameters of 

the following INCREASE (UC) 

command) 


MAC, status 






INCREASE 




If Verification of the MAC is OK, 
then update the cyclic file 

Data (new value, value added) 







Figure B.8: Scenario for DECREASE (SIVI) 
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B.9 Scenarios for downloading keys 

B.9.1 Loading of keys in an empty EFkey_man in the UC 

The purpose of this operation is to download keys in an empty EFj^y man ^^ UC. 
Minimum set of functions of SM needed to perform this operation: 

- SELECT KEYSET; 

- DIVERSIFY KEYSET; 

- GIVE RANDOM; 

- COMPUTE LOAD KEY. 

Minimum set of functions of UC needed to perform this operation: 

- ASK RANDOM; 

- LOAD KEY FILE. 

Minimum set of data in UC needed to perform this operation: 

- AID; 
diversification data; 
key. 
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SM 


TERMINAL 


USER CARD 




SELECT KEYSET (master keys of 

the EF(^£Y MAN °f **^^ "^'^t '^^^' 
above e.g. MP level) 






DIVERSIFY KEYSET (EFqiki) 


Storage of diversified l<eys in 
EFdiki 


SELECT KEYSET (master keys of 

the keys to be loaded e.g. at DF 

level) 




DIVERSIFY KEYSET (EFpiKa) 


Storage of diversified l<eys in 
E'^DIK2 


ASK RANDOM 




Challenge 


GIVE RANDOM 






COMPUTE LOAD KEY 


Enciphered key + MAC 






LOAD KEY FILE 




Storage of the key 
Status 






NOTE: Tfie key linked to the LOAD KEY FILE command shall be the last key to be changed. 



Figure B.9: Scenario for loading of one key in an empty EFf^^y man '" ^^^ ^^ 
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B.9.2 Replacing of already existing keys in the EFkey_man of the UC 

The purpose of this operation is to replace an existing key in EFj^gy man °f ^^ ^^■ 
Minimum set of functions of SM needed to perform this operation: 

- SELECT KEYSET; 

- DIVERSIFY KEYSET; 

- GIVE RANDOM; 

- COMPUTE LOAD KEY. 

Minimum set of functions of UC needed to perform this operation: 

- ASK RANDOM; 

- LOAD KEY FILE. 

Minimum set of data in UC needed to perform this operation: 

- AID; 
diversification data; 

- key. 
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SM 


TERMINAL 


USER CARD 




SELECT KEYSET (master keys of 
the EF(^£Y MAN (keyset version 
- n+1)) 






DIVERSIFY KEYSET (EFqiki) 


Storage of diversified l<eys in 


SELECT KEYSET (master keys of 
the EF^EY MAN C^^y set version n)) 




DIVERSIFY KEYSET (EFq|K2) 


Storage of diversified l<eys in 
EFdiK2 


ASK RANDOM 




Challenge 


GIVE RANDOM 






COMPUTE LOAD KEY 


Enciphiered l<ey + IVIAC 






LOAD KEY FILE 




Storage of the key 
Status 






NOTE: Tfie key linked to tine LOAD KEY FILE command shall be the last key to be changed. 



Figure B.10: Scenario for replacing a l<ey in EF^ey man '" ^^^ UC 
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B.9.3 Replacing of already existing keys in the EFkey_op of the UC 

The purpose of this operation is to replace an existing key in EFj^gy op °f ^^ UC. 
Minimum set of functions of SM needed to perform this operation: 

- SELECT KEYSET; 

- DIVERSIFY KEYSET; 

- GIVE RANDOM; 

- COMPUTE LOAD KEY. 

Minimum set of functions of UC needed to perform this operation: 

- ASK RANDOM; 

- LOAD KEY FILE. 

Minimum set of data in UC needed to perform this operation: 

- AID; 
diversification data; 

- key. 
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SM 


TERMINAL 


USER CARD 




SELECT KEYSET (master l<eys of 
tlie EF(^£Y OP (keyset version 
-n+1)) 






DIVERSIFY KEYSET (EFqiki) 


Storage of diversified l<eys in 


SELECT KEYSET (master l<eys of 
eFkey_man)) 




DIVERSIFY KEYSET (EFdik2) 


Storage of diversified l<eys in 
EFdiK2 


ASK RANDOM 




Ctiallenge 


GIVE RANDOM 






COMPUTE LOAD KEY 


Enciptiered key + cryptogram 






LOAD KEY FILE 


< 


Storage of the l<ey 
Status 





Figure B.11 : Scenario for replacing a key in EFi^^y op '" ^^^ ^^ 
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